NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/480

Internet Message Format | 1996-08-05 | 3.5 KB

Path: news.sprintlink.net!datalytics!news
From: Rob Stewart <[e-mail]>
Newsgroups: comp.lang.c++
Subject: Re: Exceptions vs. assertions
Date: 4 Jan 1996 17:08:44 GMT
Organization: Datalytics, Inc
Message-ID: <4ch1is$[e-mail]>
References: <4al1hn$[e-mail]> <4bpt9b$[e-mail]>
NNTP-Posting-Host: pc071.datalytics.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22 (Windows; I; 32bit)

[e-mail] (lalit gidwani) wrote:
>Pierre G. Boutquin ([e-mail]) wrote:
>: In <4aji1j$[e-mail]>, Bryan Larsen writes:
>: >Thanks to every
>: who replied.
>: >
>: >To sum up what I've learned -- feel free to correct me :)
[snip]
>: >2)  Exceptions are used for normal error handling, such as allocation
[snip]
>: Exceptions are used to catch catastrophic errors -- such as
>: allocation failure.  Errors that will "normally" occur in a
>: program may better be implemented in a different fashion,
>: since exceptions don't come cheaply...
[snip]
>Someone needs to point me to a proper architecture for using Exceptions.
>Several times I have come across articles that seem to apply that
>any time there is an error condition, an exception should be used.
>One of their arguments for doing this is that the program does
>not have to check for the return value of functions. The exception
>handling mechanism can be used instead. Since I have run into
>a lot of code where a lot of erro-checking has to be done I thought
>that exceptions would be helpful. However, the the note that appears
>above implies that C++ exception-handling should be used only
>for catastrophic errors.
>
>LG
>

Exceptions aren't free.  Typically, each try block you code
causes a performance hit, so limit the number of try blocks
you use the best you can.  When you throw an exception, much
occurs behind the scenes.  Throwing an exception is more
expensive (in performance terms) than a simply function
return.  If you can throw an exception for several different
reasons, you may still need to decode the reason in the catch
block, so that isn't any different from decoding an error code
returned by a function.

As a result, you should limit your use of exceptions.  Don't
be afraid of them, but don't throw them when a simple result
code would suffice, unless the sort of error you're reporting
is quite likely going to unwind a great deal of functions
calls from the stack.  Such an error is probably of the
"catastrophic" variety anyway.

For example, a disk full condition is likely to unwind
numerous functions back to some common point at which the
program notifies the user of the condition and asks how to
proceed.  The program may allow the user to repeat the action
(hopefully after the user deleted some files from the full
volume).  You could return disk full as an error code and pass
it back the call chain until you reach the right point in the
code to prompt the user.  Since there aren't likely to be many
functions in the call stack that can handle it, "disk full" is
a good candidate for an exception.

On the other hand, a more temporary failure might not be
considered catastrophic, and could be handled closer to the
troubled function call.  It really is subjective.  You can't
even say, "I'm not sure what's a bad use of exceptions, but
I'll know it when I see it."

--
Robert Stewart        | My opinions are usually my own.
Datalytics, Inc.
[phone]
[e-mail]